3.2 Access Control

RBAC

Policies

Blink uses role-based access control (RBAC) to authorize a user's actions. The authorization policy is isomorphic, so it is actually used unmodified to authorize every request in both the frontend and the backend. You can find the policy files at policies/ - it is written using CASL, so if you want to learn more about the syntax (for now the policies are pretty simple to the point where you should be able to read it even without knowing CASL), visit https://casl.js.org.

Roles

Here's what you need to know: users can have either the user or the superuser role, as defined in config/schema/user.yaml. By default, anyone who logs in/gets provisioned is a user. superusers can pretty much take any action they want, so you really want to guard access to who can get superuser role.

There are two ways to promote a user to superuser:

1. Get a superuser to promote that user
2. Be the first to sign in (which creates Blink accounts in the background and promotes it, again, for only the first user to sign up)

You can check any user's role by looking up the user in the User tab in the UI.

Deactivation

By default, anyone can sign up/provision themselves in Blink if they are authenticated with the org's SSO; in some cases, you'd want to revoke a user's access to Blink. However, if you outright delete the user from Blink, the user can simply sign back on to Blink using their SSO, and the Blink server would have no idea that the user is not meant to have access to Blink.

Therefore, instead of outright deleting the user, you deactivate a user in Blink instead (you can see the deactivate button by clicking on a user in Blink Admin UI). Once a user is deactivated, they will not be able to even login to Blink; however, the server will still remember their identity and superusers can re-activate them from the UI should they wish to do so.